前言：寫進 skill 裡的規則，AI 真的會照做嗎？

「這條規則我已經寫進 skill 了，AI 應該會照著做吧？」

這句話聽起來很合理，卻藏著一個容易被忽略的假設：skill 裡的文字規則，終究要靠 AI「記得」去執行。而 AI 會不會記得，取決於這輪對話有沒有把 skill 讀進來、有沒有把這條規則放在注意力還夠集中的地方。如果這條規則是一種可以用程式判斷對錯的機械式檢查——格式對不對、命名符不符合慣例、有沒有出現不該出現的字串——那與其賭 AI 每次都會記得檢查，不如直接寫一支 script，讓檢查這件事本身變成可以被強制執行的動作。

AI 開發工具本身也需要被當成軟體來設計——這句話今天要落在一個很具體的地方：skill 不只是給 AI 讀的文字規則，還可以附帶一支真正能跑的 script，把「機械式比對」自動化。

今日目標

• 理解「寫進 skill 的規則」跟「寫成可執行的 script」是兩種不同強度的約束
• 認識哪些規則適合寫成 script、哪些不適合
• 看懂「自動化到哪裡為止、哪裡一定要人工」這條分界該怎麼劃
• 建立「skill 附帶工具」這個設計模式的具體做法

純文字規則靠的是 AI 的注意力，script 靠的是程式邏輯

一條寫在 skill 裡的規則，執行力取決於三件事：這輪對話有沒有載入這支 skill、AI 讀到這條規則的時候有沒有把它跟眼前的任務連起來、AI 有沒有把這件事排進「要做的事」清單裡而不是漏掉。這三件事只要有一件沒發生，規則就形同虛設——而且不會有任何警訊告訴你規則被跳過了，你只會在事後發現結果不對。

一支 script 不一樣。它不需要「記得」，只需要「被執行」。你把檢查邏輯寫進程式碼，跑一次就是跑一次，結果是確定的、可重複的、不受對話長度或注意力影響。這不是說 script 比 AI 聰明，而是它們承擔的是不同性質的任務：AI 適合做需要理解上下文、需要判斷取捨的事；script 適合做規則明確、輸入輸出可以窮舉的機械式比對。

什麼規則適合寫成 script

不是所有規則都值得寫成 script。值得的規則通常有幾個特徵：判斷標準是明確的、可以用程式邏輯表達的（例如「有沒有出現某個特定字串」「命名是不是符合某種格式」），檢查頻率高、每次都要做（不是一次性的判斷），漏掉的代價不小（漏掉一次會造成實質問題，不是小瑕疵）。

反過來，需要理解語境、需要判斷「這個情況算不算例外」的規則，通常不適合寫成 script——這類判斷本來就該留給 AI 或人。硬要把這種規則塞進 script，只會寫出一堆誤判的規則，反而增加噪音。

用一組對照來看這個差異：

❌ 只把規則寫進 skill 文字，靠 AI 每次自己記得檢查：
skill 裡寫著：「發文前確認沒有出現內部代號、真實檔案路徑」
→ 這條規則的執行力，完全取決於這輪對話裡 AI 有沒有
  把這句話跟「我現在要發文了」這個動作連起來——
  對話進行到一半、規則被讀過但沒被重新想起，
  規則就悄悄失效了，而且沒有任何提示告訴你

✅ 把機械式的部分寫成 script，skill 只負責告訴 AI「要跑這支 script」：
skill 裡寫著：「發文前執行 check.sh <file>，
              exit code 非 0 就代表命中已知的識別字串清單，
              一定要修到乾淨才能發文」
→ 這條規則不再依賴 AI 的注意力，
  只依賴「有沒有執行這個指令」這個更簡單、更容易被要求的動作；
  漏掉的識別字串清單本身也可以持續累積，
  每次抓到新案例就加進清單，讓下一次掃描自動涵蓋

Script 把「這條規則有沒有被遵守」從一個需要信任 AI 記性的問題，變成一個可以被直接驗證的問題——你不用相信 AI 記得檢查，你只需要看 script 的 exit code。

自動化到哪裡為止：機械式比對交給 script，判斷交給人

這裡有個很容易被誤解的地方：script 負責「找出可能有問題的地方」，不負責「決定要不要改、怎麼改」。一支檢查 script 命中了某個模式，代表這裡「值得人工複查」，不代表這裡「一定要照 script 的意見改」——有些命中是誤判、有些命中命中了但改法需要判斷上下文才能決定。

這個分界很重要，因為如果把 script 的輸出直接當成最終答案、不經過人工複查就自動修改，會把「機械式比對容易誤判」這個弱點放大——script 抓到的是「符合某個模式」，不是「一定有問題」。把 script 當成一個「篩選器」而不是「裁判」，才能同時拿到自動化的效率跟人工判斷的準確度。

讓 script 本身持續累積規則庫

一支好的檢查 script，通常會搭配一份可以持續更新的規則清單，而不是把判斷邏輯寫死在程式碼裡。每次發現一個新的、script 原本抓不到的案例，就把對應的模式加進清單，讓下一次掃描能自動涵蓋——這樣 script 不會停留在「當初寫的時候想到的規則」，而是隨著實際踩過的坑持續變得更完整。這也呼應了這個系列反覆講的模式：一次性的踩坑經驗，要提煉成下次可以直接套用的規則，不管是提煉進 skill 的文字，還是提煉進 script 的規則清單，本質上是同一件事。

今日思考題

回想你手上有沒有一條「寫在文件裡、但常常被跳過」的規則？如果這條規則的判斷標準是明確的，你有沒有機會把它寫成一支可以自動執行的檢查？

今日重點回顧

• 純文字規則的執行力依賴 AI 的注意力（有沒有讀到、有沒有想起來），script 的執行力不依賴這件事
• 適合寫成 script 的規則：判斷標準明確、檢查頻率高、漏掉代價不小；需要判斷取捨的規則不適合
• Script 負責「找出可能有問題的地方」，不負責「決定怎麼改」——機械式比對交給 script，判斷交給人
• 好的檢查 script 搭配可持續更新的規則清單，讓自動化範圍隨著實際踩坑經驗持續擴大

明日預告

明天用一個具體案例，走一次「某類規則從每次人工複查都漏，到寫成自動化檢查工具」的完整過程——包括第一次跑這支工具就抓到人工複查漏掉的東西這個轉折點。